My SE lead is asking about how to capture variation points for a L2 requirement, such as one parameter value for platform A, and a different value for platform B. Not so much a requirment as a note to the developer that can come along with the requirement. We discussed having variation attributes, describing it in a comment type attribute, and the fact that these variation points at some level will likely become requirements and will have to be tested.
I'm wondering if I would introduce any horrible things down the road if I were to allow these "variation" objects to become children objects of a requirement object, and designated as such through an Object Type attribute so they are not counted as individual requirements right now. Evenutally, when the SEs decide that these really do need to be requirements on their own, it would be a fairly simple matter to promote them and change the object type to requirement.
Thoughts? Experiences?
SystemAdmin - Thu May 13 11:52:44 EDT 2010 |
Re: requirement objects with "children" as variation points?
llandale - Thu May 13 16:06:19 EDT 2010
Not actually done it, but we decided that it would be better to have some place holder in the Object Text, and represent these values in different Attributes; in your case named "Values Platform A" and "Values Platform B". AttrDXL would cleverly display the 'Platform A' Text by replacing the place-holders with the correct Values, as would the exporter.
Having separate Objects for each Platform figuring to filter the module to exclude non-Platform objects is a reasonable alternative, but falls apart when you have lots of Platforms, since trying to keep the text of that group of objects the same gets daunting.
|